Overall, looks good to me. Would love Kaido or Yavor to take a look as well.

I don't know how solid the idea of adding another API layer to call Starboard here looks like. It does look to me like most call sites could be trivially updated to simply use base::File that routes to Starboard underneath - except in very few limited places. @andrewsavage1 please have a look as well, wdyt ?

The stats tracking could then be entirely contained only in base::File with maybe another place or two.

It does look to me like most call sites could be trivially updated to simply use base::File that routes to Starboard underneath - except in very few limited places

I actually didn't see any places that couldn't use base::File, I definitely think that's a good option.

Otherwise this looks okay to me now. Two things - now that @y4vor is back, i'd like him to have a look at the general concept. Note, the assumption is that we will only have base::File calling StarboardFile, all other call sites will be migrated to use base::File.

So really the two remaining call sites to increment those counters are going to be base/files/file_starboard.cc and cobalt/storage/savegame_starboard.cc.

Second, for some reason i'm not very keen on having a top-level starboard_stats/ module. I logically understand it should be above starboard/ and below base/ in the chain of dependencies. I'd still love to move it to starboard/common or a little more tucked away.

I almost wonder if statstracker interface starboard_stats::StatsTracker class couldn't simply be replaced with two simple callback functions or observers ?